Service request common object

ABSTRACT

Service request information in a first format for use by a first computerized system is synchronized with the service request information in a second computerized system that utilizes a second format by using an service request common object data model.

CROSS REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional PatentApplication No. 60/457,305 filed Mar. 24, 2003, entitled, “SERVICEREQUEST COMMON OBJECT,” by Barnes et al., and which is herebyincorporated by reference in its entirety.

TECHNICAL FIELD

The present invention is directed to the field of data modeling in thecontext of enterprise resources planning and customer relationsmanagement, and more specifically to service request management.

BACKGROUND

Many enterprise systems use call centers to interface with customers.Such call centers may use call center business processes to processcustomer requests. An example of a customer request is a request forservice or “service request”.

For example, assume that a customer calls to report a loss of service. Aloss of service is also referred to herein as a network outage. Callcenter agents face a challenge to manage customer service requests andthe network outages in the shortest amount of time. The call center isreferred to as the front-office.

Typically, network outages are managed by a network operations center(NOC). The network operations center is referred to as the back-office.Further, the individuals who act as call center agents are distinct fromthe individuals in the network operations center. The two groupstypically do not communicate with each other. In addition, the callcenter and the network operations center, each use differentapplications. For example, the call center agents use a call centerapplication in the call center's computerized system to record customertechnical problems as service requests. On the other hand, the networkoperations center uses technical applications such as a networkmanagement system in the network operation's computerized system todetect and fix problems such as network outages.

Typically, the call center applications are not linked to the networkmanagement systems. Although the network management system can detectand recognize a network outage, such information is usually notcommunicated to the call center agents and the call center applications.Therefore, when a customer contacts the call center to report a loss ofservice, the call center is usually not aware of the network outage. Inresponse to a customer's complaint regarding the network outage, thecall center agent collects the network outage information as a ticketand sends the ticket to the appropriate individuals to resolve theticket.

Thus, a mechanism is needed to synchronize the information associatedwith service requests and network outages between the front-officeapplications, e.g., the call center applications, with the back officeapplications, e.g., the network management system applications.

Generally, in order for front-office computerized systems to communicatewith back-office computerized systems or vice versa, the user mustmanually regenerate data from the back-office computerized systems informs usable by the front-office computerized systems, and vice versa.Such manual regeneration has several significant disadvantages,including: (1) it is often expensive; (2) it often requires asubstantial amount of time to complete; (3) it must be repeated eachtime data changes in either the back-office system or the front-officesystem; and (4) it is prone to errors.

In view of the foregoing, an automated approach for synchronizing dataused by a back-office computerized system with data that is use by afront-office computerized system, and vice versa, is needed.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1A is a high level network diagram showing aspects of acomputerized environment in which the facility operates, according tocertain embodiments.

FIG. 1B is a block diagram showing some of the components typicallyincorporated in at least some of the computer systems and other deviceson which the facility executes.

FIG. 2 is a high level flow diagram that shows some steps typicallyperformed by the facility in order to convert service requestinformation from the one or more source formats to the target format.

FIG. 3A illustrates some a process flow for fulfilling a servicerequest.

FIG. 3B illustrates a process flow for an online self-service to obtainservice requests.

FIG. 4 illustrates an integration business process (IBP) forSynchronizing service request information between the source and targetsystems.

FIG. 5 to FIG. 17 are data structure diagrams of the service requestcommon object model.

DETAILED DESCRIPTION

When a customer contacts the call center to report a loss of service,the call center is usually not aware of the network outage because thecall center applications are not linked to the network managementsystems. Although the network management system can detect and recognizea network outage, such information is usually not communicated to thecall center agents and the call center applications. A more proactivemethod would be to synchronize the service request information andnetwork outage information by linking the network management systemapplications to the call center applications.

The synchronization operation provides users associated with the callcenter and network operations the same view of customer service requestsand network outage information across the various computer applications.All changes in the customer service requests and the network outageinformation need to be captured and made accessible to all relevantcomputer applications in the enterprise system. The computerapplications of the front-office system uses a data model that isdistinct from the data model used in back-office system's computerapplications. Thus, a common data storage model is needed so that thevarious computer applications across the enterprise system can share theservice request information and network outage information.

According to certain embodiments, the front-office applications such asthe call center applications can be linked to the back-officeapplications such as the network operations applications by using a datamodel that includes a service request common object.

If the network management system applications are linked to the callcenter applications using a service request common object, then when anetwork outage occurs, the network management system can communicatewith the call center. For example, the network management system canrequest that a service request be opened in the call center application.If a customer calls to report the network outage, the call center agentwould be able to verify the customer's outage and report the currentactivity on the opened service request.

Call centers may use certain call center business processes to processcustomer requests. Such call center business processes may enable a callcenter agent to perform the following:

-   -   1) initiate or create a service request in a multi-application        integration system (MAIS);    -   2) capture the details of the service request    -   3) verify entitlements;    -   4) research and resolve the service request;    -   5) escalate service requests (if necessary);    -   6) create customer orders (if necessary); and    -   7) close service request.

A software facility (hereafter “the facility”) for automaticallysynchronizing service request information, is described. In someembodiments, the facility converts service request information from aform used by the source system to a form used by the target system. Incertain embodiments, source systems may be front-office systems such ascustomer call centers. In certain embodiments, target systems may beback-office system providing support for network operations. However,the network operations center may need to initiate service requestinformation, then the network operations center is referred to as thesource system and the call center becomes the target system.

In some embodiments, such as embodiments adapted to converting servicerequest information in the first source format, the facility convertsservice request information by converting the service requestinformation that is in the first source format into an intermediateformat. The intermediate format is then used to convert the servicerequest information into the target format.

By performing such conversions, embodiments of the facility enable auser of a first computerized system who has stored service requestinformation in a first format for use by the first computerized systemto readily make the stored service request information available for usein a second computerized system that utilizes a second format in acost-efficient and time-efficient manner.

FIG. 1A is a network diagram showing aspects of a typical hardwareenvironment in which the facility operates. FIG. 1A shows a sourcesystem 110, a target system 130, an integration server 120 and a network150. Source system 110 stores service request information in a sourceformat. There may be more than one source system. Target system 130stores service request information in a target format. Target system 130is described in greater detail herein, with reference to FIG. 1B.

The facility (not shown) converts some or all service requestinformation that is in the source format into the target format by usingan intermediate format of the service request information. In certainembodiments, such conversions are performed with the aid of one or moreother computer systems, such as integration server system 120.Components of the facility may reside on and/or execute on anycombination of these computer systems, and intermediate results from theconversion may similarly reside on any combination of these computersystems.

The computer systems shown in FIG. 1A are connected via network 150,which may use a variety of different networking technologies, includingwired, guided or line-of-sight optical, and radio frequency networking.In some embodiments, the network includes the public switched telephonenetwork. Network connections established via the network may befully-persistent, session-based, or intermittent, such as packet-based.While the facility typically operates in an environment such as is shownin FIG. 1A and described above, those skilled in the art will appreciatethe facility may also operate in a wide variety of other environments.

FIG. 1B is a block diagram showing some of the components typicallyincorporated in at least some of the computer systems and other deviceson which the facility executes, including some or all of the server andclient computer systems shown in FIG. 1A. These computer systems anddevices 100 may include one or more central processing units (“CPUs”)101 for executing computer programs; a computer memory 102 for storingprograms and data—including data structures—while they are being used; apersistent storage device 103, such as a hard drive, for persistentlystoring programs and data; a computer-readable media drive 104, such asa CD-ROM drive, for reading programs and data stored on acomputer-readable medium; and a network connection 105 for connectingthe computer system to other computer systems, such as via the Internet,to exchange programs and/or data—including data structures. Whilecomputer systems configured as described above are typically used tosupport the operation of the facility, those skilled in the art willappreciate that the facility may be implemented using devices of varioustypes and configurations, and having various components.

It will be understood by those skilled in the art that the facility maytransform service request information from a number of different sourcesystems and from a number of different source software packages to anumber of target systems and/or to a number of target software packages.

FIG. 2 is a high level flow diagram that shows some steps typicallyperformed by the facility in order to convert service requestinformation from the one or more source formats to the target format. Atblock 201, the facility extracts service request information from one ormore source systems. At block 202, the facility converts the extractedinformation into an intermediate format. The intermediate format isdescribed in greater detail herein, with reference to the common objectdata model. At block 203, the facility synchronizes the service requestinformation from the source system with that of the target system byconverting the service request information in intermediate format intothe target format. After block 203, the steps as shown in FIG. 2conclude.

The steps shown in FIG. 2 may be repeated periodically, either toconvert service request information that is changed in the source systemsince the last conversion, and/or to convert one or more particularlyselected service request information. The facility may performconversions from various source systems on which is executing varioussource software packages, and/or convert service request information tovarious target systems executing different target software packages.

Efficiency of the service request capture and resolution may be measuredwith the following indicators: 1) number of service requests (by area,by customer, by severity, by source, etc.), 2) open service requests bytime to resolve, by owner, by account, by age, etc., 3) number of closedservice requests by time to resolve, by account, by area, by time period(month, week, day), etc.

FIG. 3A illustrates some a process flow for fulfilling a servicerequest. At block 302, the customer reports a service issue to acustomer service representative over the phone. The customer servicerepresentative identifies the customer and inquires if the call isregarding a new or existing issue. a customer service representativeinvestigates a service request in response to a customer calling intothe call center. If the customer is new, then a new contact is createdfor the customer before proceeding with the call.

At block 304, the customer service representative issues queries to seeif there are any existing open service requests for this customer. Ifthe service issue is related to an existing service request then thecustomer service representative provides status to the customer andupdates the service request with any new information provided by thecustomer. If the service issue is not related to any service request,then a new service request is created and all details are entered forthis new service request.

At block 306, the customer service representative verifies if thecustomer is entitled to receive the service associated with the servicerequest. If the customer is not entitled to receive service, then theagent informs the customer about the same and transfers the call to asales order agent to order a service agreement.

At block 308, if the customer is entitled, then the customer servicerepresentative either takes ownership of the service request or assignsthe service request to the appropriate person who can work on theservice request.

At block 310, the customer service representative researches the servicerequest and attempts to resolve the service request. At block 312, thecustomer service representative determines whether the customer issatisfied with the resolution of the service request. If the customer isnot satisfied with the solution, or if the issue is not resolved withinthe commit time, then at block 314, the customer service representativeattempts to escalate the service request by contacting the appropriatedepartments. If it is determined that the customer is satisfied, then atblock 316, the customer service representative determines whether theresolution of the service request requires delivery of parts to thecustomer. If it is determined that parts are to be delivered, then atblock 318, the customer service representative creates an order for theneeded parts. Otherwise, if parts are not needed then at block 320, theservice request is completed.

FIG. 3B illustrates a process flow for an online self-service to obtainservice requests. An online self-service business process enablescustomers and partners to create, update, track, and sometimes resolvetheir service requests online. At block 350, the customer logs into theself-service web site. At block 352, the customer either submits a newservice request or updates an existing service request.

At block 354, for an existing service request the customer queries forthe service request, checks the status, and updates the service requestwith new information. At block 356, the updated information is sent tothe MAIS to update the corresponding service request.

At block 358, for a new service request the customer creates a servicerequest and fills in the details. At block 360, the new service requestinformation is sent to the MAIS to create the service request.

FIG. 4 illustrates an integration business process (IBP) forSynchronizing service request information between the source and targetsystems. At block 402, when a customer calls about a new service issue,the customer service representative captures the details of the serviceissue by creating a new service request. At block 404, this servicerequest information is used to create a service request object that isreferred to by both the source and target systems using thesynchronization service request process. During the course of resolutionof a service request, the service request information undergoes severalmodifications including addition of new activities, changes to status,owners, commit time, area, sub-area, addition of solutions/resolutiondocuments, etc. At block 406, the synchronization service requestprocess synchronizes the target system with the latest updatedinformation from the source system (MAIS) and vice versa by using theservice.request object.

The primary variables of a service request object are: 1) contact, 2)account, 3) asset or product. When the service request is created, theservice request is linked to one or more of the above primary variables.Additionally, variables such as severity, area, sub-area, summary,description, etc., may be passed. If the service request already exists,then the IBP updates all of the service request variables/fields thatchanged since the last update or creation of the service request. Table1 summarizes some of aspects associated with the service request objectand synchronization service request process. TABLE 1 Type Send ModeAsynchronous Sender MAIS applications, Micromuse, Remedy ApplicationReceiver Micromuse, Remedy, MAIS applications Application VBC or DataData Replication Replication Primary Actor Customer ServiceRepresentative, Automatic events (Micromuse) Supporting Service manager,external (target) applications Actors Precondition All Contact, Account,Asset, and Product information that exist in MAIS should be synchronizedwith external (target) systems and Vice Versa. Minimal MAIS to external(target) system: A Service request is created Guarantees in the externalsystem even if Account and Contact details cannot be found. If theservice request already exists, then at least the key fields/recordssuch as commit time, Area, Sub-area, Owner, Status, activities within aservice request, are updated. External (target) system to MAIS: AService request is created in MAIS even if Account and Contact detailscannot be found. If the service request already exists, then at leastthe key fields/records such as commit time, Area, Sub-area, Owner,Status, activities within a service request, are updated. Success MAISto external (target) system: A Service request is Guaranteescreated/updated in the external system with all details such as account,contact, activities, etc., populated or updated. External system(target) to MAIS: A Service request is created/updated in MAIS with alldetails such as account, contact, activities, etc., populated orupdated. Trigger Information should be sent out after a record is savedin the database Condition Area = “Network” if the target application isMicromuse. This should be configurable by the MAIS administrator. Noconditions if Remedy is the target application. Post Step None MAIS BOService Requests Package Size One Service Request and all the relevantdetails Master Data Account, Contact, Products, Activities, Assets,Solutions Dependencies Remote data Service Requests should be set inmode “To be submitted” requirement which should happen when usersconnects to the network Send List of Service Requests Account InfoContact Info service request Information (Area, Sub-area, Status, etc.)Asset Information Product Info Activities Type, Description, owner, etc.Audit Trail Info on all changes Receive None. Comments

Once an service request is created or updated and saved in MAIS, thesame information is sent to the external (target) system to create orupdate the same service request. With respect to the process flow fromthe external (target) system to MAIS, once a trouble ticket or servicerequest is created or updated in the external (target) system or anevent is triggered, information is sent to MAIS to create or update theservice request.

The Service Request Common Object includes the following information:

-   -   Service request number: System generated alpha-numeric code that        identifies a service request uniquely.    -   Account Name: Name of the account that the service request        belongs to.    -   Site: Location of the account.    -   Summary: Brief description of reasons for logging a service        request.    -   Description: Detailed description or explanation of the customer        problems, issues, etc., which requires assistance.    -   Contact last name: Last name of the contact that logged the        service request.    -   Contact first name: First name of the contact that logged the        service request.    -   Status: Indicates the current status of the service request        (Open, Closed, Pending, etc.).    -   Sub-status: Indicates the current sub-status of the service        request based on the status selected. For example, potential        sub-status values could be “Waiting for info”, “More info        needed”, etc., for status=“Open”.    -   Source: Indicates the channel (Phone, Web, Email, etc.) through        which the service request was logged.    -   Area: Identifies the category (Hardware, Software, Network        support, etc.) that the service request belongs to.    -   Sub-area: Identifies the sub-category within a category.    -   Priority: Customer's rating or ranking (Very high, High, Medium,        etc.) that identifies the degree of customer's importance in        resolving the service request.    -   Severity: Customer service center's ranking of the service        request based on its own assessment.    -   Owner: Employee ID of the person that is responsible for        resolving the service request.    -   Time Opened: System time stamp when the service request was        opened.    -   Time Closed: System time stamp when the service request was        closed.    -   Time Committed: Indicates a point in time before which the        customer should be responded to in resolving the service        request.    -   Product: Indicates the product that is associated with the        service request.    -   Part number: Manufacturer's code for identifying the product        associated with the service request.    -   Asset number: Internal company code that uniquely identifies the        product associated with the service request.    -   Profile: List of external products that could have potential        interactions with the product identified above.

Thus, the service request common object provides a unique, flexible,common data structure to represent various types of service requests formost industries. The service requests can be assigned to anyorganization, person or business unit. The service request common objectalso carries information about Parent Area, Sub Area, Product &environment data, Asset Number and Status/Priority codes. List of allactivities performed (internal and published ) can also be transferredusing the service request common object.

The service request can be associated with various Contacts, Owners,Organization. The Service request can also be associated with eitherProduct or Installed Product. Also, environment information can becommunicated using External Product and or External Installed product.

FIG. 5 to FIG. 17 are data structure diagrams of the service requestcommon object model. Such a service request common object modelillustrates sample intermediate data structure that can containinformation to be synchronized between the source and target systems.

FIG. 5 is a block diagram that illustrates the components of a servicerequest object as described herein. In FIG. 5, the service requestcommon object includes a list of service request element 502, which inturn includes any number of service request components 504. The servicerequest common object has a basic Type called ServiceRequestType asshown in the following figure. ServiceRequestType contains components ofservice request common object such as:

Common Id 506;

Base Data 508;

Related parent Area 510;

Related Root area 512;

Related Contract 514;

List of Related Contacts 516;

List of Related Account (Customer) 518;

List of Related Owner 520;

Status Data 522;

Related Product (both Internal and External) 524;

Related Installed Product (Customer Asset) 526;

Related Business Unit 528;

List of Related Activity 530; and

Service request custom data 532.

In FIG. 6, the illustrated intermediate data structure 600 is of typeservice request base data. Base data 602 may include the followingcomponents:

-   -   Abstract 604 (summary of requested service);    -   Channel source code 606 (e.g. phone, web, email, fax, etc.);    -   Closed Date 608 (date when service request is closed);    -   Commit time 610 (time before which to respond to the customer        for resolving the service request);    -   Description 612 (detailed description or explanation of the        customer problems, issues, etc., which require assistance);    -   Number 614 (service request number); and    -   Reported date 616.

In FIG. 7, the illustrated intermediate data structure 700 is of typeservice request related parent area. Service request related parent area702 includes a parent area component 704, which in turn may include thefollowing components:

-   -   ID 706 (common ID of the functional area);    -   Base data 708 that can include a functional area name 714;    -   List of related sub-areas 710 that can include any number of        related sub-areas 716; and    -   Functional area custom data 712.

In FIG. 8, the illustrated intermediate data structure 800 is of typeservice request related root area. Service request related root area 802includes an ID component 804, which is the common ID of the functionalarea of the service request.

In FIG. 9, the illustrated intermediate data structure 900 is of typeservice request related contracts. The related contract component 902may include an ID 904, a related contract base data 906, and a relatedcontract custom data 908. The related contract base data 906 may includethe following components:

-   -   Description 910 of the related contract;    -   Effective-to date 912 (up to what date is the contract        effective);    -   Type code 914 (e.g., field services, service, etc.);    -   Number 916 (contract number);    -   Effective-from date 918 (from what date is the contract        effective);    -   Response code 920 (such as support codes, e.g., 24X7, service,        e.g., 24X5 service) and    -   Response time 922.

In FIG. 10, the illustrated intermediate data structure 1000 is of typeservice request list of related contact. The list of related contactcomponent 1002 may include any number of related contacts 1004. Eachrelated contact may include the following components:

-   -   ID 1006 (common ID of a party);    -   Communication data 1008 (communication data for a party);    -   Data cleansing data 1010 (i.e., data that is related to data        cleansing);    -   List of address 1012 (address of a party);    -   List of relationship 1014 (relationships that a party can have        with other entities);    -   List of alternate ID 1016;    -   List of License data 1018;    -   Custom party data 1020;    -   Person base data 1022;.    -   Privacy data 1024; and    -   Custom data 1026 for the related contact.

In FIG. 11, the illustrated intermediate data structure 1100 is of typeservice request list of related account. The list of related accountcomponent 1102 may include a related account component 1104, which inturn may include the following components:

-   -   ID 1106 (common ID of a party);    -   Communication data 1108 (communication data for a party);    -   Data cleansing data 1110 (i.e., data that is related to data        cleansing);    -   List of address 1112 (address of a party);    -   List of relationship 1114 (relationships that a party can have        with other entities);    -   List of alternate ID 1116;    -   List of License data 1118;    -   Custom party data 1120;    -   Base data 1122; and    -   Custom data 1124; and

In FIG. 12, the illustrated intermediate data structure 1200 is of typeservice request list of related owner. The list of related ownercomponent 1202 may include any number of related owners 1204 (assigneesof the service request). Each related owner may include the followingcomponents:

-   -   ID 1206 (common ID of a party);    -   Communication data 1208 (communication data for a party);    -   Data cleansing data 1210 (i.e., data that is related to data        cleansing);    -   List of address 1212 (address of a party);    -   List of relationship 1214 (relationships that a party can have        with other entities);    -   List of alternate ID 1216;    -   List of License data 1218;    -   Custom party data 1220;    -   Person base data 1222;    -   Privacy data 1224; and    -   Custom data 1226 for the related owner.

In FIG. 13, the illustrated intermediate data structure 1300 is of typeservice request status data. The status data component 1302 may includethe following components:

-   -   Priority code 1304;    -   Severity code 1306    -   Status code 1308; and    -   Sub-status code 1310.

In FIG. 14, the illustrated intermediate data structure 1400 is of typeservice request related product. The related product component 1402 mayinclude the following components:

-   -   ID 1404 (product ID);    -   Base data 1406 (product base data);    -   Sales data 1408 (product sales data);    -   Configuration data 1410;    -   Related product line 1412;    -   List of price type 1414 (collection of valid price types for        this product);    -   List of related inventory location 1416 (collection of valid        inventory locations e.g. warehouses, plants, that stock this        product);    -   List of related product 1418;    -   List of related business unit 1420 (sales organizations that are        authorized to sell this product); and    -   Custom data 1422 (product custom data reserved for use by the        customer).

In FIG. 15, the illustrated intermediate data structure 1500 is of typeservice request related installed product. The related installed productcomponent 1502 may include the following components:

-   -   ID 1503 (common ID of an installed product);    -   Base data 1504;    -   Related parent installed Product 1506;    -   Pricing data 1508;    -   Related product 1510;    -   List of related party 1512 (account and owner of the installed        product);    -   List of related order 1514;    -   Related inventory location 1516;    -   Related business unit 1518;    -   List of attribute 1520;    -   Custom data 1522; and    -   List of related installed product 1524 (list of related external        installed products associated with the installed product on the        service request).

Further, the list of related installed product may include any number ofa related external products 1526. Each related external product 1526 mayinclude the following components:

-   -   ID 1528 (product ID);    -   Base data 1530 (product base data);    -   Sales data 1532 (product sales data);    -   Configuration data 1534;    -   Related product line 1536;    -   List of price type 1538 (collection of valid price types for        this product);    -   List of related inventory location 1540 (collection of valid        inventory locations e.g. warehouses, plants, that stock this        product);    -   List of related product 1542;    -   List of related business unit 1544 (sales organizations that are        authorized to sell this product); and    -   Custom data 1546 (product custom data reserved for use by the        customer).

In FIG. 16, the illustrated intermediate data structure 1600 is of typeservice request related business unit. Service request related businessunit 1602 includes an ID component 1604.

In FIG. 17, the illustrated intermediate data structure 1700 is of typeservice request list of related activity. The list of related activitycomponent 1702 may include any number of related activities 1704. Eachrelated activity component may include the following components:

-   -   Access code 1706 (e.g., private, audience, internal, etc.);    -   Comment 1708 (additional comments on action taken);    -   Duration 1710 (e.g., count, day, hour, etc.);    -   End date 1712;    -   Number 1714 (activity number);    -   Reason code 1716 (e.g., quality, defect, scheduled maintenance,        un-scheduled maintenance, etc.);    -   Start date 1718;    -   Task description 1720 (description of action taken);    -   Type code 1722 (category of work, e.g., meeting, admin, etc.);        and    -   Related owner 1705.

It will be appreciated by those skilled in the art that theabove-described facility may be straightforwardly adapted or extended invarious ways. For example, the facility may be used to transform variousother kinds of service request information, and may be used to transformservice request information between a variety of other formats.

In the foregoing specification, embodiments of the invention have beendescribed with reference to numerous specific details that may vary fromimplementation to implementation. Thus, the sole and exclusive indicatorof what is the invention, and is intended by the applicants to be theinvention, is the set of claims that issue from this application, in thespecific form in which such claims issue, including any subsequentcorrection. Any express definitions set forth herein for terms containedin such claims shall govern the meaning of such terms as used in theclaims. Hence, no limitation, element, property, feature, advantage orattribute that is not expressly recited in a claim should limit thescope of such claim in any way. The specification and drawings are,accordingly, to be regarded in an illustrative rather than a restrictivesense.

1. A method in a computing system for managing a service request, themethod comprising: extracting service request information in a firstform that is associated with a first source computerized service requestmanagement system; converting the service request information in thefirst form into service request information that is in a secondintermediate form; and converting the service request information in thesecond intermediate form into service request information in a targetform that corresponds to a target computerized service requestmanagement system.
 2. The method of claim 1, further comprising: usingthe service request information in the target form to perform at leastone computer-implemented act from a set of computer-implemented actscomprising: creating a new service request record in the targetcomputerized service request management system; and updating an existingservice request record in the target computerized service requestmanagement system.
 3. The method of claim 1, further comprising:extracting service request information in a third form that isassociated with a second source computerized service request managementsystem that is distinct from the first source computerized servicerequest management system; converting the service request information inthe third form into service request information that is in the secondintermediate form; converting the service request information in thesecond intermediate form into service request information in the targetform; and using the service request information in the target form toperform at least one computer-implemented act from a set ofcomputer-implemented acts comprising: creating a new service requestrecord in the target computerized service request management system; andupdating an existing service request record in the target computerizedservice request management system.
 4. The method of claim 1, wherein thesecond intermediate form includes a list of service request element witha hierarchy of data components.
 5. The method of claim 4, wherein thehierarchy of data components includes a plurality of service requestcomponents, wherein each of the plurality of service request componentsincludes one or more of: a service request common ID component; aservice request base data component; a related parent area component; arelated root area component; a related contract component; a list ofrelated contacts component; a list of related account component; a listof related owner component; a status data component; a related productcomponent for defining internal and external products; a relatedinstalled product component for defining customer assets; a relatedbusiness unit component; a list of related activity component; and aservice request custom data component.
 6. The method of claim 5, whereinthe service request base data component includes one or more of: anabstract component for summarizing the service request; a channel sourcecode component; a closed date component for defining when the servicerequest is closed; a commit time component; a description component; aservice request number component; and a reported date component.
 7. Themethod of claim 5, wherein the related parent area component includes aparent area component, wherein the parent area component includes one ormore of: a functional area common ID component; a base data componentthat can include a functional area name component; a list of relatedsub-areas component that can include any number of related sub-areacomponents; and a functional area custom data component.
 8. The methodof claim 5, wherein the related root area component includes a common IDfor functional area.
 9. The method of claim 5, wherein the relatedcontract component includes one or more of: a contract common IDcomponent; a contract base data component, wherein contract base datacomponent includes one or more of: a related contract descriptioncomponent; an effective-to date component; a type code component; acontract number component; an effective-from date component; a responsecode component; a response time component; and a related contract customdata component.
 10. The method of claim 5, wherein the list of relatedcontact component includes a plurality of related contact components,wherein each of the plurality of related contact components includes oneor more of: a common ID for a party component; a communication data fora party component; a data cleansing data component; a list of address ofa party component; a list of relationships that a party can have withother entities component; a list of alternate ID component; a list oflicense data component; a custom party data component; a person basedata component; a privacy data component; and a related contact customdata component.
 11. The method of claim 5, wherein the list of relatedaccount component includes a plurality of related account components,wherein each of the plurality of related account components includes oneor more of: a common ID for a party component; a communication data fora party component; a data cleansing data component; a list of address ofa party component; a list of relationships that a party can have withother entities component; a list of alternate ID component; a list oflicense data component; a custom party data component; a party base datacomponent; and a related contact custom data component.
 12. The methodof claim 5, wherein the list of related owner component includes aplurality of related owner components, wherein each of the plurality ofrelated owner components includes one or more of: a common ID for aparty component; a communication data for a party component; a datacleansing data component; a list of address of a party component; a listof relationships that a party can have with other entities component; alist of alternate ID component; a list of license data component; acustom party data component; a person base data component, a privacydata component; and a related contact custom data component.
 13. Themethod of claim 5, wherein the status data component includes one ormore of: a priority code component; a severity code component; a statuscode component; and a sub-status code component.
 14. The method of claim5, wherein the related product component includes one or more of: aproduct ID component; a product base data component; a product salesdata component; a configuration data component; a related product linecomponent; a list of price type component; a list of related inventorylocation component; a list of related product component; a list ofrelated business unit component; and a product custom data component.15. The method of claim 5, wherein the related installed productcomponent includes one or more of: a common ID of an installed productcomponent; an installed product base data component; a related parentinstalled product component; a pricing data component; a related productcomponent a list of related party component; a list of related ordercomponent; a related inventory location component; a related businessunit component; a list of attribute component; a custom data component;and a list of related installed product component, wherein the list ofrelated installed product component includes one or more of: an externalproduct ID component; an external product base data component; anexternal product sales data component; an external product configurationdata component; an external product related product line component; anexternal product list of price type component; an external product listof related inventory location component; an external product list ofrelated product component; an external product list of related businessunit component; and an external product custom data component.
 16. Themethod of claim 5, wherein the related business unit component includesa related business unit common ID.
 17. The method of claim 5, whereinthe list of related activity component includes a plurality of relatedactivity components, wherein each of the plurality of related activitycomponents includes one or more of: an access code component; a commenton action taken component; a duration component; an end date component,an activity number component; a reason code component; a start datecomponent; a task description of action taken component; a type codecomponent; and a related owner component.
 18. A computer-readable mediumcarrying one or more sequences of instructions for managing a servicerequest, wherein execution of the one or more sequences of instructionsby one or more processors causes the one or more processors to perform:extracting service request information in a first form that isassociated with a first source computerized service request managementsystem; converting the service request information in the first forminto service request information that is in a second intermediate form;and converting the service request information in the secondintermediate form into service request information in a target form thatcorresponds to a target computerized service request management system.19. The computer-readable medium of claim 18, further comprising: usingthe service request information in the target form to perform at leastone computer-implemented act from a set of computer-implemented actscomprising: creating a new service request record in the targetcomputerized service request management system; and updating an existingservice request record in the target computerized service requestmanagement system.
 20. A data structure for managing a service request,the data structure comprising a list of service request element with ahierarchy of data components.
 21. The data structure of claim 20,wherein the hierarchy of data components includes a plurality of servicerequest components, wherein each of the plurality of service requestcomponents includes one or more of: a service request common IDcomponent; a service request base data component; a related parent areacomponent; a related root area component; a related contract component;a list of related contacts component; a list of related accountcomponent; a list of related owner component; a status data component; arelated product component for defining internal and external products; arelated installed product component for defining customer assets; arelated business unit component; a list of related activity component;and a service request custom data component.
 22. The data structure ofclaim 21, wherein the service request base data component includes oneor more of: an abstract component for summarizing the service request; achannel source code component; a closed date component for defining whenthe service request is closed; a commit time component; a descriptioncomponent; a service request number component; and a reported datecomponent.
 23. The data structure of claim 21, wherein the relatedparent area component includes a parent area component, wherein theparent area component includes one or more of: a functional area commonID component; a base data component that can include a functional areaname component; a list of related sub-areas component that can includeany number of related sub-area components; and a functional area customdata component.
 24. The data structure of claim 21, wherein the relatedroot area component includes a common ID for functional area.
 25. Thedata structure of claim 21, wherein the related contract componentincludes one or more of: a contract common ID component; a contract basedata component, wherein contract base data component includes one ormore of: a related contract description component; an effective-to datecomponent; a type code component; a contract number component; aneffective-from date component; a response code component; a responsetime component; and a related contract custom data component.
 26. Thedata structure of claim 21, wherein the list of related contactcomponent includes a plurality of related contact components, whereineach of the plurality of related contact components includes one or moreof: a common ID for a party component; a communication data for a partycomponent; a data cleansing data component; a list of address of a partycomponent; a list of relationships that a party can have with otherentities component; a list of alternate ID component; a list of licensedata component; a custom party data component; a person base datacomponent; a privacy data component; and a related contact custom datacomponent.
 27. The data structure of claim 21, wherein the list ofrelated account component includes a plurality of related accountcomponents, wherein each of the plurality of related account componentsincludes one or more of: a common ID for a party component; acommunication data for a party component; a data cleansing datacomponent; a list of address of a party component; a list ofrelationships that a party can have with other entities component; alist of alternate ID component; a list of license data component; acustom party data component; a party base data component; and a relatedcontact custom data component.
 28. The data structure of claim 21,wherein the list of related owner component includes a plurality ofrelated owner components, wherein each of the plurality of related ownercomponents includes one or more of: a common ID for a party component; acommunication data for a party component; a data cleansing datacomponent; a list of address of a party component; a list ofrelationships that a party can have with other entities component; alist of alternate ID component; a list of license data component; acustom party data component; a person base data component; a privacydata component; and a related contact custom data component.
 29. Thedata structure of claim 21, wherein the status data component includesone or more of: a priority code component; a severity code component; astatus code component; and a sub-status code component.
 30. The datastructure of claim 21, wherein the related product component includesone or more of: a product ID component; a product base data component; aproduct sales data component; a configuration data component; a relatedproduct line component; a list of price type component; a list ofrelated inventory location component; a list of related productcomponent; a list of related business unit component; and a productcustom data component.
 31. The data structure of claim 21, wherein therelated installed product component includes one or more of: a common IDof an installed product component; an installed product base datacomponent; a related parent installed product component; a pricing datacomponent; a related product component a list of related partycomponent; a list of related order component; a related inventorylocation component; a related business unit component; a list ofattribute component; a custom data component; and a list of relatedinstalled product component, wherein the list of related installedproduct component includes one or more of: an external product IDcomponent; an external product base data component; an external productsales data component; an external product configuration data component;an external product related product line component; an external productlist of price type component; an external product list of relatedinventory location component; an external product list of relatedproduct component; an external product list of related business unitcomponent; and an external product custom data component.
 32. The datastructure of claim 21, wherein the related business unit componentincludes a related business unit common ID.
 33. The data structure ofclaim 21, wherein the list of related activity component includes aplurality of related activity components, wherein each of the pluralityof related activity components includes one or more of: an access codecomponent; a comment on action taken component; a duration component; anend date component; an activity number component; a reason codecomponent; a start date component; a task description of action takencomponent; a type code component; and a related owner component.